Controlling access to content based on certificates and access predicates

ABSTRACT

Digital rights for content downloaded to a subscriber computer from a provider are specified in an access predicate. The access predicate is compared with a rights manager certificate associated with an entity, such as an application, that wants access to the content. If the rights manager certificate satisfies the access predicate, the entity is allowed access to the content. A license that specifies limitations on the use of the content can also be associated with the content and provided to the entity. The use the entity makes of the content is monitored and terminated if the entity violates the license limitations. In one aspect of the invention, the access predicate and the license are protected from tampering through cryptographic techniques.

RELATED APPLICATIONS

This application is a continuation-in-part of U.S. provisional patentapplication Ser. No. 60/105,891 filed on Oct. 26, 1998, which is hereinincorporated by reference, and is related to co-pending and co-filedU.S. patent applications titled “System and Method for Authenticating anOperating System to a Central Processing Unit, Providing the CPU/OS withSecure Storage, and Authenticating the CPU/OS to a Third Party” U.S.Ser. No. 09/266,207, “Loading and Identifying a Digital RightsManagement Operating System” U.S. Ser. No. 09/227,611, “Key-based SecureStorage.” U.S. Ser. No. 09/227,568, and “Digital Rights ManagementOperating System” U.S. Ser. No. 09/227,561.

FIELD OF THE INVENTION

This invention relates generally to computer operating systems, and moreparticularly to a computer operating system that enforces digitalrights.

COPYRIGHT NOTICE/PERMISSION

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever. The following notice applies to the software and dataas described below and in the drawings hereto: Copyright© 1998,Microsoft Corporation, All Rights Reserved.

BACKGROUND OF THE INVENTION

More and more content is being delivered in digital form, and more andmore digital content is being delivered online over private and publicnetworks, such as Intranets, the Internet and cable TV networks. For aclient, digital form allows more sophisticated content, while onlinedelivery improves timeliness and convenience. For a publisher, digitalcontent also reduces delivery costs. Unfortunately, these worthwhileattributes are often outweighed in the minds of publishers by thecorresponding disadvantage that online information delivery makes itrelatively easy to obtain pristine digital content and to pirate thecontent at the expense and harm of the publisher.

Piracy of digital content, especially online digital content, is not yeta great problem. Most premium content that is available on the Web is oflow value, and therefore casual and organized pirates do not yet see anattractive business stealing and reselling content. Increasingly,though, higher-value content is becoming available. Books and audiorecordings are available now, and as bandwidths increase, video contentwill start to appear. With the increase in value of online digitalcontent, the attractiveness of organized and casual theft increases.

The unusual property of digital content is that the publisher (orreseller) gives or sells the content to a client, but continues torestrict rights to use the content even after the content is under thesole physical control of the client. For instance, a publisher willtypically retain copyright to a work so that the client cannot reproduceor publish the work without permission. A publisher could also adjustpricing according to whether the client is allowed to make a persistentcopy, or is just allowed to view the content online as it is delivered.These scenarios reveal a peculiar arrangement. The user that possessesthe digital bits often does not have full rights to their use; instead,the provider retains at least some of the rights. In a very real sense,the legitimate user of a computer can be an adversary of the data orcontent provider.

“Digital rights management” is therefore fast becoming a centralrequirement if online commerce is to continue its rapid growth. Contentproviders and the computer industry must quickly provide technologiesand protocols for ensuring that digital content is properly handled inaccordance with the rights granted by the publisher. If measures are nottaken, traditional content providers may be put out of business bywidespread theft, or, more likely, will refuse altogether to delivercontent online.

Traditional security systems ill serve this problem. There are highlysecure schemes for encrypting data on networks, authenticating users,revoking certificates, and storing data securely. Unfortunately, none ofthese systems address the assurance of content security after it hasbeen delivered to a client's machine. Traditional uses of smart cardsoffer little help. Smart cards merely provide authentication, storage,and encryption capabilities. Ultimately, useful content must beassembled within the host machine for display, and again, at this pointthe bits are subject to theft. Cryptographic coprocessors providehigher-performance cryptographic operations, and are usuallyprogrammable but again, fundamentally, any operating system orsufficiently privileged application, trusted or not, can use theservices of the cryptographic processor.

There appear to be three solutions to this problem. One solution is todo away with general-purpose computing devices and use special-purposetamper-resistant boxes for delivery, storage, and display of securecontent. This is the approach adopted by the cable industry and theirset-top boxes, and looks set to be the model for DVD-video presentation.The second solution is to use secret, proprietary data formats andapplications software, or to use tamper-resistant software containers,in the hope that the resulting complexity will substantially impedepiracy. The third solution is to modify the general-purpose computer tosupport a general model of client-side content security and digitalrights management.

This invention is directed to a system and methodology that fallsgenerally into the third category of solutions.

A fundamental building block for client-side content security is asecure operating system. If a computer can be booted only into anoperating system that itself honors content rights, and allows onlycompliant applications to access rights-restricted data, then dataintegrity within the machine can be assured. This stepping-stone to asecure operating system is sometimes called “Secure Boot.” If secureboot cannot be assured, then whatever rights management system thesecure OS provides, the computer can always be booted into an insecureoperating system as a step to compromise it.

Secure boot of an operating system is usually a multi-stage process. Asecurely booted computer runs a trusted program at startup. The trustedprogram loads an initial layer of the operating system and checks itsintegrity (by using a code signature or by other means) before allowingit to run. This layer will in turn load and check the succeeding layers.This proceeds all the way to loading trusted (signed) device drivers,and finally the trusted application(s).

An article by B. Lampson, M. Abadi, and M. Burrows, entitled“Authentication in Distributed Systems: Theory and Practice,” ACMTransactions on Computer Systems v10, 265, 1992, describes in generalterms the requirements for securely booting an operating system. Theonly hardware assist is a register that holds a machine secret. Whenboot begins this register becomes readable, and there's a hardwareoperation to make this secret unreadable. Once it's unreadable, it staysunreadable until the next boot. The boot code mints a public-key pairand a certificate that the operating system can use to authenticateitself to other parties in order to establish trust. We note that inthis scheme, a malicious user can easily subvert security by replacingthe boot code.

Clark and Hoffman's BITS system is designed to support secure boot froma smart card. P. C. Clark and L. J. Hoffman, “BITS: A SmartcardOperating System,” Comm. ACM. 37, 66, 1994. In their design, the smartcard holds the boot sector, and PCs are designed to boot from the smartcard. The smart card continues to be involved in the boot process (forexample, the smart card holds the signatures or keys of other parts ofthe OS).

Bennet Yee describes a scheme in which a secure processor first getscontrol of the booting machine. B. Yee, “Using Secure Coprocessors”,Ph.D. Thesis, Carnegie Mellon University, 1994. The secure processor cancheck code integrity before loading other systems. One of the nicefeatures of this scheme is that there is a tamper-resistant device thatcan later be queried for the details of the running operating system.

Another secure boot model, known as AEGIS, is disclosed by W. Arbaugh,D. G. Farber, and J. M Smith in a paper entitled “A Secure and ReliableBootstrap Architecture”, Univ. of Penn. Dept. of CIS Technical Report,IEEE Symposium on Security and Privacy, page 65, 1997. This AEGIS modelrequires a tamper-resistant BIOS that has hard-wired into it thesignature of the following stage. This scheme has the very considerableadvantage that it works well with current microprocessors and thecurrent PC architecture, but has three drawbacks. First, the set oftrusted operating systems or trusted publishers must be wired into theBIOS. Second, if the content is valuable enough (for instance, e-cash orHollywood videos), users will find a way of replacing the BIOS with onethat permits an insecure boot. Third, when obtaining data from a networkserver, the client has no way of proving to the remote server that it isindeed running a trusted system.

On the more general subject of client-side rights management, severalsystems exist or have been proposed to encapsulate data and rights in atamper-resistant software package. An early example is IBM's Cryptolope.Another existent commercial implementation of a rights management systemhas been developed by Intertrust. In the audio domain, AT&T Researchhave proposed their “A2b” audio rights management system based on thePolicyMaker rights management system.

Therefore, there is a need in the art for a digital rights managementoperating system that enforces digital rights on content downloaded froma provider while operating on a general purpose personal computerwithout the need of specialized or additional hardware.

SUMMARY OF THE INVENTION

The above-mentioned shortcomings, disadvantages and problems areaddressed by the present invention, which will be understood by readingand studying the following specification.

Digital rights for content downloaded to a subscriber computer from aprovider are specified in an access predicate. The access predicate iscompared with a rights manager certificate associated with an entity,such as an application, that wants access to the content. If the rightsmanager certificate satisfies the access predicate, the entity isallowed access to the content. A license that specifies limitations onthe use of the content can also be associated with the content andprovided to the entity. The use the entity makes of the content can bemonitored and terminated if the entity violates the license limitations.In one aspect of the invention, the access predicate and the license areprotected from tampering through cryptographic techniques.

Because the digital rights imposed on the content by the provider aredownloaded to the subscriber computer along with the content, a generalpurpose computer only needs to load a digital rights managementoperating system that utilizes the rights information to become atrusted subscriber. Specifying the properties through a rights managercertificate allows an easy comparison between the properties of anentity wishing access to the content and those required by the contentprovider.

The present invention describes systems, clients, servers, methods, andcomputer-readable media of varying scope. In addition to the aspects andadvantages of the present invention described in this summary, furtheraspects and advantages of the invention will become apparent byreference to the drawings and by reading the detailed description thatfollows.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a diagram of the hardware and operating environment inconjunction with which exemplary embodiments of the invention may bepracticed;

FIG. 1B is a diagram of a client computer for use with exemplaryembodiments of the invention;

FIG. 2 is a diagram illustrating a system-level overview of an exemplaryembodiment of the invention;

FIG. 3 is a flowchart of a method to be performed by a client whenbooting or loading system components according to an exemplaryembodiment of the invention;

FIG. 4 is a diagram of a certificate revocation list data structure foruse in an exemplary implementation of the invention;

FIG. 5 is a flowchart of a method to be performed by a client to createa boot log according to an exemplary embodiment of the invention;

FIG. 6 is a block diagram of an exemplary boot log created using themethod of FIG. 5;

FIGS. 7A, 7B and 7C are block diagrams of boot blocks for use in anexemplary embodiment of the invention;

FIG. 8 is a block diagram of key generation functions according to anexemplary embodiment of the invention;

FIG. 9 is a diagram of a rights manager certificate data structure foruse in an exemplary implementation of the invention;

FIG. 10 is a diagram of a required properties access control list datastructure for use in an exemplary implementation of the invention; and

FIG. 11 is a diagram of a license data structure for use in an exemplaryimplementation of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of exemplary embodiments of theinvention, reference is made to the accompanying drawings, which form apart hereof, and in which is shown by way of illustration specificexemplary embodiments in which the invention may be practiced. Theseembodiments are described in sufficient detail to enable those skilledin the art to practice the invention, and it is to be understood thatother embodiments may be utilized and that logical, mechanical,electrical and other changes may be made without departing from thespirit or scope of the present invention. The following detaileddescription is, therefore, not to be taken in a limiting sense, and thescope of the present invention is defined only by the appended claims.

The detailed description is divided into four sections. In the firstsection, the hardware and the operating environment in conjunction withwhich embodiments of the invention may be practiced are described. Inthe second section, a system level overview of the invention ispresented. The third section described methods and data structuresemployed by various exemplary embodiments of the invention. Finally, inthe fourth section, a conclusion of the detailed description isprovided.

Hardware and Operating Environment

FIG. 1A is a diagram of the hardware and operating environment inconjunction with which embodiments of the invention may be practiced.The description of FIG. 1A is intended to provide a brief, generaldescription of suitable computer hardware and a suitable computingenvironment in conjunction with which the invention may be implemented.Although not required, the invention is described in the general contextof computer-executable instructions, such as program modules, beingexecuted by a computer, such as a personal computer. Generally, programmodules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types.

Moreover, those skilled in the art will appreciate that the inventionmay be practiced with other computer system configurations, includinghand-held devices, multiprocessor systems, microprocessor-based orprogrammable consumer electronics, network PCs, minicomputers, mainframecomputers, and the like. The invention may also be practiced indistributed computing environments where tasks are performed by remoteprocessing devices that are linked through a communications network. Ina distributed computing environment, program modules may be located inboth local and remote memory storage devices.

The exemplary hardware and operating environment of FIG. 1A forimplementing the invention includes a general purpose computing devicein the form of a computer 20, including a processing unit 21, a systemmemory 22, and a system bus 23 that operatively couples various systemcomponents, including the system memory 22, to the processing unit 21.There may be only one or there may be more than one processing unit 21,such that the processor of computer 20 comprises a singlecentral-processing unit (CPU), or a plurality of processing units,commonly referred to as a parallel processing environment. The computer20 may be a conventional computer, a distributed computer, or any othertype of computer; the invention is not so limited.

The system bus 23 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. The system memorymay also be referred to as simply the memory, and includes read onlymemory (ROM) 24 and random access memory (RAM) 25. A basic input/outputsystem (BIOS) 26, containing the basic routines that help to transferinformation between elements within the computer 20, such as duringstart-up, is stored in ROM 24. The computer 20 further includes a harddisk drive 27 for reading from and writing to a hard disk, not shown, amagnetic disk drive 28 for reading from or writing to a removablemagnetic disk 29, and an optical disk drive 30 for reading from orwriting to a removable optical disk 31 such as a CD ROM or other opticalmedia.

The hard disk drive 27, magnetic disk drive 28, and optical disk drive30 are connected to the system bus 23 by a hard disk drive interface 32,a magnetic disk drive interface 33, and an optical disk drive interface34, respectively. The drives and their associated computer-readablemedia provide nonvolatile storage of computer-readable instructions,data structures, program modules and other data for the computer 20. Itshould be appreciated by those skilled in the art that any type ofcomputer-readable media that can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memories (RAMs), read onlymemories (ROMs), and the like, may be used in the exemplary operatingenvironment.

A number of program modules may be stored on the hard disk, magneticdisk 29, optical disk 31, ROM 24, or RAM 25, including an operatingsystem 35, one or more application programs 36, other program modules37, and program data 38. A user may enter commands and information intothe personal computer 20 through input devices such as a keyboard 40 andpointing device 42. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit21 through a serial port interface 46 that is coupled to the system bus,but may be connected by other interfaces, such as a parallel port, gameport, or a universal serial bus (USB). A monitor 47 or other type ofdisplay device is also connected to the system bus 23 via an interface,such as a video adapter 48. In addition to the monitor, computerstypically include other peripheral output devices (not shown), such asspeakers and printers.

The computer 20 may operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer 49.These logical connections are achieved by a communication device coupledto or a part of the computer 20; the invention is not limited to aparticular type of communications device. The remote computer 49 may beanother computer, a server, a router, a network PC, a client, a peerdevice or other common network node, and typically includes many or allof the elements described above relative to the computer 20, althoughonly a memory storage device 50 has been illustrated in FIG. 1. Thelogical connections depicted in FIG. 1 include a local-area network(LAN) 51 and a wide-area network (WAN) 52. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN-networking environment, the computer 20 is connectedto the local network 51 through a network interface or adapter 53, whichis one type of communications device. When used in a WAN-networkingenvironment, the computer 20 typically includes a modem 54, a type ofcommunications device, or any other type of communications device forestablishing communications over the wide area network 52, such as theInternet. The modem 54, which may be internal or external, is connectedto the system bus 23 via the serial port interface 46. In a networkedenvironment, program modules depicted relative to the personal computer20, or portions thereof, may be stored in the remote memory storagedevice. It is appreciated that the network connections shown areexemplary and other means of and communications devices for establishinga communications link between the computers may be used.

The hardware and operating environment in conjunction with whichembodiments of the invention may be practiced has been described. Thecomputer in conjunction with which embodiments of the invention may bepracticed may be a conventional computer, a distributed computer, or anyother type of computer; the invention is not so limited. Such a computertypically includes one or more processing units as its processor, and acomputer-readable medium such as a memory. The computer may also includea communications device such as a network adapter or a modem, so that itis able to communicatively couple to other computers.

One exemplary embodiment of a suitable client computer is described inthe related application titled “System and Method for Authenticating anOperating System to a Central Processing Unit, Providing the CPU/OS withSecure Storage, and Authenticating the CPU/OS to a Third Party,” andillustrated in FIG. 1B as subscriber unit 124. The CPU 140 in thesubscriber unit 124 is able to authenticate the identity of the bootblock and OS components that have been loaded into the computer, and toprovide quoting and secure storage operations based on this identity asbriefly described next. Full descriptions of various embodiments for thesubscriber unit 124 are provided in the related application.

The CPU 140 has a processor 160 and also can have a cryptographicaccelerator 162. The CPU 140 is capable of performing cryptographicfunctions, such as signing, encrypting, decrypting, and authenticating,with or without the accelerator 162 assisting in intensive mathematicalcomputations commonly involved in cryptographic functions.

The CPU manufacturer equips the CPU 140 with a pair of public andprivate keys 164 that is unique to the CPU. For discussion purpose, theCPU's public key is referred to as “K_(CPU)” and the correspondingprivate key is referred to as “K_(CPU) ⁻¹”. Other physicalimplementations may include storing the key on an external device towhich the main CPU has privileged access (where the stored secrets areinaccessible to arbitrary application or operating systems code). Theprivate key is never revealed and is used only for the specific purposeof signing stylized statements, such as when responding to challengesfrom a content provider, as is discussed below.

The manufacturer also issues a signed certificate 166 testifying that itproduced the CPU according to a known specification. Generally, thecertificate testifies that the manufacturer created the key pair 164,placed the key pair onto the CPU 140, and then destroyed its ownknowledge of the private key “K_(CPU) ⁻¹”. In this way, only the CPUknows the CPU private key K_(CPU) ⁻¹; the same key is not issued toother CPUs and the manufacturer keeps no record of it. The certificatecan in principle be stored on a separate physical device associated withthe processor but still logically belongs to the processor with thecorresponding key.

The manufacturer has a pair of public and private signing keys, K_(MFR)and K_(MFR) ⁻¹. The private key K_(MFR) ⁻¹is known only to themanufacturer, while the public key K_(MFR) is made available to thepublic. The manufacturer certificate 166 contains the manufacturer'spublic key K_(MFR), the CPU's public key K_(CPU), and the abovetestimony. The manufacture signs the certificate using its privatesigning key, K_(MFR) ⁻¹, as follows:

Mfr. Certificate=(K_(MFR), Certifies-for-Boot, K_(CPU)), signed byK_(MFR) ⁻¹ The predicate “certifies-for-boot” is a pledge by themanufacturer that it created the CPU and the CPU key pair according to aknown specification. The pledge further states that the CPU cancorrectly perform authenticated boot procedures, as are described belowin more detail. The manufacturer certificate 66 is publicly accessible,yet it cannot be forged without knowledge of the manufacturer's privatekey K_(MFR) ⁻¹.

The CPU 140 has an internal software identity register (SIR) 168, whichcontains the identity of an authenticated operating system 180 or apredetermined false value (e.g., zero) if the CPU determines that theoperating system 180 cannot be authenticated. The operating system (OS)180 is stored in the memory 142 and executed on the CPU 140. Theoperating system 180 has a block of code 182 that is used toauthenticate the operating system to the CPU during the boot operation.The boot block 182 uniquely determines the operating system, or class ofoperating systems (e.g. those signed by the same manufacturer). The bootblock 182 can also be signed by the OS manufacturer.

SYSTEM LEVEL OVERVIEW

A system level overview of the operation of an exemplary embodiment ofthe invention is described by reference to FIG. 2. A subscriber computer200, such as client computer 20 in FIG. 1, is connected to a contentprovider server computer 220, such as remote computer 49, through awide-area network, such as WAN 52. Processes performed by the componentsof the subscriber computer 200 and the content provider 220 areillustrated by arrows in FIG. 2. Many of these processes incorporateeither public/private key pairs, digital signatures, digitalcertificates, and/or encryption algorithms, or a combination of thesestandard cryptographic functions. Such functions are assumed to beprovided by the CPU of the subscriber computer in the descriptions thatfollow, but can be provided by other well-known cryptographic mechanismsas will be immediately understood by one skilled in the art.

To prevent their content from being stolen or misused, content providerswill download content only to known software, and therefore only tosubscriber computers that can prove that their operating systems willenforce the limitations the provider places on the content. Such adigital rights management operating system (DRMOS) must load and executeonly OS components that are authenticated as respecting digital rights(“trusted”), and must allow access to the downloaded content by onlysimilarly trusted applications.

The first requirement is met in the exemplary embodiment of theinvention by having all trusted operating system-level componentsdigitally signed by their developers or a trusted third-party, with thesignature acting as a guarantee that the components respect digitalrights. The signature is validated before the component is loaded. Theresulting DRMOS is assigned a unique trusted identity, as explained indetail below, which is recorded in an internal register in the CPU, suchas SIR 168 in FIG. 1B. FIG. 2 illustrates a DRMOS 205, with its identity206, after it has been loaded into the CPU 201 of a subscriber computer200 through such a loading process 1.

The second requirement has two aspects. First, trusted applications mustbe identified in some fashion, and, second, the DRMOS must preventnon-trusted applications from gaining access to the content when it isstored, either permanently or temporarily, on the subscriber computer.

In the exemplary embodiment shown in FIG. 2, a trusted application 209has agreed to operate in accordance with the limitations placed oncontent by a provider. The trusted application 209 is identified througha “rights manager” certificate 210. In one embodiment, the rightsmanager certificate 210 extends a standard digital certificate, whichincludes such items as date of publication and name of the application,by adding a list of services, or properties, provided by theapplication, i.e., content type handled, version of the application,whether it saves content to disk, etc. For purposes of the exemplaryembodiment shown in FIG. 2, the certificate 210 also identifies thetrusted application; alternate mechanisms for identifying a trustedapplication are described later in the methods section.

The DRMOS 205 provides key-secured storage for permanently storedcontent to prevent unauthorized access to the content. For temporarilystored content, the DRMOS 205 prevents an untrusted process from readingthe memory holding the content. These and other safeguards are alsodescribed in detail below. The permanent and temporary storage withinsubscriber computer 200 are collectively represented by device 203,which is illustrated in FIG. 2 as a disk drive. Such illustration is notintended to limit the range of devices that can serve as secured storagefor a DRMOS.

Turning now to the remainder of the processes depicted in FIG. 2,application 209 requests 2 the download of content 221 from provider220. The DRMOS 205 sends a message 3 to the provider 220 requesting thecontent 221. The content provider 220 transmits a challenge message 4 tothe DRMOS 205 asking for the identity of the CPU 201, the DRMOS 205, andthe application 209. The DRMOS 205 transmits a response message 5containing a certificate 202 for the CPU 201, its own identity 206, andthe rights manager certificate 210 for the application 209.

The challenge-response process follows the common protocol for suchinterchanges, the difference being only in the data exchanged betweenthe subscriber computer and the content provider. In one exemplaryembodiment of a suitable challenge-response process described in therelated application titled “System and Method for Authenticating anOperating System to a Central Processing Unit, Providing the CPU/OS withSecure Storage, and Authenticating the CPU/OS to a Third Party,” thecertificate 202 contains the challenge message 3, the identity of theDRMOS 206, the public key of the CPU 201, and data representing allsoftware components that are currently loaded and executing on thesubscriber computer 200. The certificate 202 is signed using the privatekey of the CPU 201. The content provider 220 examines the CPUcertificate 202, the DRMOS identity 206, and the properties specified inthe rights manager certificate 210 to determine whether it shouldestablish a trust relationship with the DRMOS 205 on the subscribercomputer 200.

In an alternate exemplary embodiment, the challenge-response protocolruns over a secure connection such as SSL (Secure Socket Layer) or TLS(Transport Level Security), which relies on a session key to encrypt thedata transferred between the subscriber computer 200 and the contentprovider 220. This stops an attacker (such as the legitimate owner ofthe machine) from rebooting the PC into a different operating systemafter the DRMOS has authenticated itself, or using a different computeron the network for snooping on the data destined for the DRMOS.

If the trust relationship is established, the provider downloads 6 thecontent 221, an access predicate 222, and a “license” 223 to the DRMOS205 on the subscriber computer 200. The access predicate 222 specifiesthe properties that an application must have in order to process thecontent 221, such as read-only or minimum/maximum video resolution. Theaccess predicate 222 may also specify specific applications or familiesof applications allowed to process the content 221. The license 223places restrictions on the use of the content 221 by an approvedapplication, such as the number of times the content can be accessed orwhat derivative use can be made of the content.

When the DRMOS 205 receives the content 221, the access predicate 222and the license 223, it determines whether the content should bepermanently stored in a key-secured storage. If so, it requests anapplication storage key from the CPU 201. In the present example, theapplication storage key is specific to the application 209 thatrequested the content 221. The content 221 and the license 223 areencrypted using the application storage key and the access predicate 222is attached to the encrypted information. If the content 221 is to bestored only temporarily, the DRMOS 205 places various safeguards aroundthe memory area holding the content so that the content cannot beaccessed by an untrusted application. The generation of applicationstorage keys and the memory safeguards are described in detail below.

Each time application 209 wants to access the stored content 221, itpasses its rights manager certificate 210 and the appropriateapplication storage key (action 8) to the DRMOS 205. The DRMOS 205validates the key and compares the rights manager certificate 210against the access predicate 222. Assuming the storage key isauthenticated and the rights manager certificate 210 satisfies theaccess predicate 222, the content 221 and the license 223 are decrypted.The DRMOS determines if the application's use of the content ispermitted under the license 223 and allows access 9 if it is.

The system level overview of the operation of an exemplary embodiment ofthe invention has been described in this section of the detaileddescription. A series of processes and data structures on a subscribercomputer control the loading of a digital rights management operatingsystem, identify the DRMOS and trusted applications to a contentprovider, and secure content downloaded by the provider to thesubscriber computer. While the invention is not limited to anyparticular hardware and software, for sake of clarity only a minimalhardware and software configuration necessary to process multimedia hasbeen assumed for the subscriber computer.

METHODS OF EXEMPLARY EMBODIMENTS OF THE INVENTION

In the previous section, a system level overview of the operation ofexemplary embodiments of the invention was described. In this section,the particular methods performed by a subscriber computer, or client, ofsuch exemplary embodiments are described by reference to a series offlowcharts and operational diagrams. The methods to be performed by theclient constitute computer programs made up of computer-executableinstructions. Describing the methods by reference to flowcharts andoperational diagrams enables one skilled in the art to develop suchprograms including such instructions to carry out the methods onsuitable computerized clients (e.g., on the processor of a clientexecuting the instructions from computer-readable media). Datastructures necessary to perform the methods are also described in thissection. The methods of the content provider server computer aredescribed to complete the understanding of the methods performed by theclient.

Although many of the methods are interrelated, they have been dividedinto four groups to facilitate understanding. The boot/load process andvarious mechanisms for creating identities for different versions of adigital right management operating system (DRMOS) are first described.The functions that must be provided by the DRMOS to ensure theenforcement of the content providers' rights are described next. Thethird group consists of methods directed toward providing permanentstorage of the content on the subscriber computer once downloaded, andprotecting that content from unauthorized access. Finally, theidentification of trusted applications and the rights managementfunctions are described.

Booting/Loading and Identifying the DRMOS

Referring first to FIG. 3, a flowchart of a method to be performed by asubscriber computer according to an exemplary embodiment of theinvention is shown. This method is inclusive of the acts required to betaken by the computer to boot a DRMOS or to load additional componentsafter the boot process is complete. Exemplary embodiments of boot blockdata structures are described below in conjunction with FIGS. 7A-C.

Shortly after a computer is turned on or is reset, a small programcalled a boot loader is executed by the CPU (block 301). The boot loaderloads a boot block for a particular operating system. Code in the bootblock then loads various drivers and other software components necessaryfor the operating system to function on the computer. The totality ofthe boot block and the loaded components make up the identity of theoperating system.

For a DRMOS, that identity can be trusted only if the boot block and theloaded components are trusted. In the embodiments described herein, allcomponents are signed by a trusted source and provided with a rightsmanager certificate. An exemplary embodiment of the rights managercertificate is described below in conjunction with FIG. 9.

The operating system checks the signature of a component before loadingit (block 303). If the signature is valid (block 305), the component hasnot been compromised by someone attempting to circumvent the bootprocess and the process proceeds to check the level of trust assigned tothe component (block 307). If the signature is not valid (or is there isno signature) but the component must be loaded (block 319), theoperating system will not assume the identity of a DRMOS upon completionof the boot process as explained further below.

A plug-and-play operating system provides an environment in whichdevices and their supporting software components can be added to thecomputer during normal operation rather than requiring all components beloaded during the boot process. If the device requires the loading of anuntrusted component after the boot process completes, a plug-and-playDRMOS must then “renounce” its trusted identity and terminate anyexecuting trusted applications (block 323) before loading the component.The determination that an untrusted component must be loaded can bebased on a system configuration parameter or on instructions from theuser of the computer.

Assuming the signature is valid (block 305) and the component is trusted(block 309), it is loaded (block 311). The trustworthiness of acomponent can be decided using various criteria. In one embodiment, onlycomponents provided by the operating system developer are trusted. Atthe other end of the scale, in another embodiment, all components areassumed trustworthy by the DRMOS, leaving the final decision to thecontent provider as described in more detail below. Still a thirdalternate embodiment provides that components signed by any of a selectnumber of entities can be considered as equivalent to componentsprovided by the DRMOS developer. In this embodiment, the identity of theresulting operating system is considered equivalent to the “pure” DRMOSprovided by the DRMOS developer. The content provider decides whether ittrusts the equivalent operating system.

Furthermore, not all versions of a component may be trusted. Because therights manager certificate contains the version number of the component,it can be used to verify the trust level of a particular version. Oneembodiment of the loading process checks a component certificationrevocation list (CRL) to determine whether a component signature hasbeen revoked. The CRL can be provided by the content provider or theDRMOS developer. An exemplary embodiment of a CRL is illustrated in FIG.4. Each entry 401 contains the name of the component 403, the version405, and the signer 407 whose signature is revoked. The particular CRLused becomes part of the operating system identity using a standardhashing function described further below.

Alternatively, if the rights manager certificates on the components areshort-lived and must be renewed periodically, then a version that isfound to be untrustworthy will not have its certificate renewed. Thisalternate embodiment requires a secure time source to be available onthe subscriber computer so the user cannot simply turn back the systemclock on the subscriber computer. A monotonic counter in the CPU canserve as this secure time source since it only counts up and cannot bereset “back in time.” For example, a monotonic counter that isperiodically incremented while the CPU is active, and that cannot bereset, can be used in conjunction with a secure time service, such as asecure Internet time service, to provide a lower bound on the currenttime in a trusted manner. Such exemplary use of a monotonic counter isdescribed in detail below as part of the functions of the DRMOS.

Once all components are loaded, the operating system assumes itsidentity (block 315). In one embodiment, a one-way hashing functionprovided by the CPU is used to create a cryptographic “digest” of allthe loaded components. The digest becomes the identity for the operatingsystem and is recorded in an internal register in the CPU. Alternatemethodologies of assigning an identity to the loaded components areequally applicable as long as a non-trusted configuration cannot havethe same identity as a DRMOS. Signing the operating system identity witha private key particular to the type of CPU serves to identify both theoperating system and the processor on which it is executing.

If all computers were identically configured, a single, signed operatingsystem identity would suffice to authenticate a particular operatingsystem executing on a particular type of CPU. However, computers containa myriad different hardware components, and the corresponding supportingsoftware components are frequently updated to add enhancements and fixproblems, resulting in a virtually unlimited number of operating systemidentities. Therefore, the content provider would have to maintain aregistry of each subscriber's DRMOS identity or delegate that functionto a trusted third party.

The problems attendant on having a vast number of DRMOS identities canbe alleviated in at least three ways. First, an identity is generated orassigned for the basic configuration of each operating system. Such abasic configuration includes only components supplied by the operatingsystem vendor. The identity is generated (or assigned) and stored whenthe basic components have been loaded. Different versions of the basicoperating system will generate (or be assigned) different identities.

Once the basic configuration of a DRMOS is loaded and its trustedidentity is stored, subsequent components required to support theparticular hardware configuration must be verified and loaded asexplained in conjunction with FIG. 3. Such additional softwarecomponents can also include updates to the basic components provided byvendors other than the operating system developer. Each additionalloaded component has an individual identity (such as a cryptographicdigest) generated/assigned and stored. All the identities are uploadedto the content provider when the DRMOS identity is requested. Becausethe basic DRMOS and additional components always have the sameidentities when executing on a specific type of processor, the contentprovider has only to maintain a list of the identities for thecombinations of the basic DRMOS and additional components that theprovider trusts. Each identity uploaded is then checked against thelist.

In a second alternate embodiment, the operating system maintains a “bootlog,” containing the identity of the basic DRMOS and the identities ofthe additional OS components that have been loaded. The identity is acryptographic digest of the code for the component, or a well-knownname, or any other string that is uniquely associated with thecomponent. The CPU also maintains a composite identity register thatholds a one-way cryptographic function of the boot log. Whenever acomponent is loaded, its identity is appended to the boot log and foldedinto the composite identity register, such as by setting this registerto a secure hash of its old value appended with the new component'sidentity. Whenever the CPU certifies the current value of its compositeidentity register, it also verifies that the operating system's boot loghas not been tampered with. Because the log is indelible, the loadedcomponent cannot erase the record that shows it was loaded.

An alternate exemplary embodiment of the boot log holds the entire bootlog in the CPU. The DRMOS uses an instruction provided by the CPU thatappends the identity of each loaded component to the log. The CPU thensigns the boot log to attest to its validity and delivers the signedboot log to the content provider as the identity for the DRMOS.

In another alternate embodiment, DRMOS uses a chain of public andprivate key pairs newly generated by the CPU to create an indelible bootlog. The method is shown in FIG. 5 and an exemplary embodiment of thecompleted boot log is illustrated in FIG. 6. The boot loader generatesor obtains a first key pair (K₀, K₀ ⁻¹) and records the first key pairin memory (block 501). The first public key is also saved to securestorage in the CPU. The boot loader loads the boot block into memory andrecords the identity of the boot block in the boot log (block 503).Before turning control over to the boot block code, the boot loaderobtains a second key pair (K₁, K₁ ⁻¹) (block 505), writes the secondpublic key (K₁) to the boot log (block 507), and then signs the boot logwith the first private key (K₀ ⁻¹) (block 509). The boot loader deletesthe first private key (K₀ ⁻¹) from its memory (block 511) andrelinquishes control to the boot block.

The boot block code loads additional components into memory, records theidentities of those components to the boot log (block 515), obtains athird key pair (K₂, K₂ ⁻¹) (block 505), appends the boot log with thethird public key (K₂) (block 507), and signs its portion of the boot logwith the second private key K₁ ⁻¹ (block 509). The boot block erases thesecond private key (K₁ ⁻¹) (block 511) from memory and turns control ofthe boot process over to the first loaded component. Each loadedcomponent that will load additional components obtains a new key pair(K_(n), K_(n) ⁻¹) and uses the private key of the previous key pair(K_(n-1) ⁻¹) to sign its portion of the boot log. The boot processcontinues in this iterative manner through until all components areloaded or, in the case of a plug-and-and play DRMOS, a content providerchallenge is received (block 513).

When a non-plug-and-play DRMOS resumes control after the final componentis loaded, it places a “sentinel” on the boot log (block 519) toindicate that the log is complete and to prevent a loaded component fromdeleting entire lines of the log. The characteristics of the sentinelare that is a known, unique value that is signed using the last privatekey (K_(n) ⁻¹). In the present embodiment, the sentinel is a signed zeroentry. The DRMOS deletes the last private key and all public keys frommemory after creating the sentinel.

Because a plug-and-play DRMOS cannot arbitrarily declare that allcomponents are loaded at the end of the boot process, the DRMOS cannotadd a sentinel to the end of the boot log at that time. Instead, theDRMOS attests to its most recent public key K_(n) as well as its firstpublic key K₀ to certify the contents of the boot log when challenged.

Using a chain of key pairs 606, 607, as shown in FIG. 6, guarantees theboot log reflects the loaded components. Each public key in a logsection is used to authenticate the signature on the next section. Thefirst public key remains in memory to authenticate the signature on theboot block section of the log. While each set of components is free toload more components, a component cannot change the recording of itsidentity in a previous portion of the log because doing so would causethe validity check on the corresponding signature to fail. Similarly, asection in the middle of the log cannot be deleted because that wouldbreak the chain of keys. Deleting multiple sections of the log throughto the end also breaks the chain. In this case, attempting to insert anew sentinel in an effort to make the log appear unaltered will failbecause the private key necessary to add the sentinel is no longeravailable. Finally, the entire boot log cannot be replaced since thesignature on the boot block section of the log would not be validated bythe first public key.

Turning now to the boot block, one exemplary embodiment suitable for usewith a digital rights management operating system is shown in FIG. 7A.The boot code 701 is signed (signature 703) by the developer of theDRMOS using its private key. The corresponding public key 705 of thedeveloper is attached to the boot block 700. In an alternate embodiment,the public key 705 is not attached to the boot block 700, but instead ispersistently stored in an internal register in the CPU. The public key705 is used to validate the signature 703.

If the DRMOS developer's private key used to sign the boot block iscompromised, the key pair must be changed and thus all boot blocks mustbe reissued to subscriber computers. FIG. 7B illustrates an alternateembodiment of a boot block that ameliorates this problem. Boot block 710comprises a basic boot section 711 and an intermediate boot section 713.The basic boot section 711 contains boot code 715 that validates andloads the intermediate boot section 713 and components not provided bythe DRMOS developer. The intermediate boot section 713 contains bootcode 717 that validates and loads components from the DRMOS developer.The intermediate boot section 713 is signed with a special boot blockprivate key. The basic boot code 715 uses a corresponding boot blockpublic key 719 stored in the basic boot section 711 to validate theintermediate boot section 713. Components 727 from the DRMOS developerare signed 729 with the developer's standard private key and theintermediate boot section 713 uses the DRMOS developer's standard publickey 721 to validate those components.

If the standard private key used to sign components is compromised, thedeveloper creates a new standard key pair and provides a replacementintermediate boot block 713 containing the new standard public key.Replacement components signed with the new standard private key are alsoissued. Because the special boot block private key is used for few, ifany, other purposes than signing boot blocks, it is less likely to becompromised and replacement of the basic boot section 711 will rarely benecessary.

In FIG. 7C, an alternate embodiment of the single section boot block 730also uses a special boot block key pair. The boot block 730 contains thespecial boot block, or master, public key 733. The master private key isused to certify ephemeral keys that are valid for a short period oftime. Certificates signed 737 by the master private key attest to thevalidity of the ephemeral keys. A component is signed with one of theephemeral private keys and the corresponding certificate 739 isattached. The boot block determines that the certificate on thecomponent is valid using the master public key. When the ephemeral keyexpires, the DRMOS developer issues replacement components. As with thetwo-section boot block shown in FIG. 7B, the master private key is onlyused to sign the certificates for the ephemeral keys so it is lesslikely to be compromised. Because the ephemeral keys are valid for onlya short duration, public release of a private ephemeral key has limitedimpact.

Functions of a DRMOS

As described above, components may be valid only until a specified dateand time, and content may also be licensed only until a certain date andtime. The monotonic counter described earlier can also be used to ensurethat the computer's clock cannot be set backwards to allow thereplacement of a trusted component by an earlier, now untrusted version.The DRMOS connects on a regular basis to a trusted time server andpresents the value of its monotonic counter, whereupon the trusted timeserver returns a certificate binding that value to the current time. Ifthe monotonic counter is updated periodically, such as every hour thatthe DRMOS is running, then the monotonic counter in conjunction with themost recent time certificate can serve as a useful approximation to atrusted clock.

A DRMOS must also protect the content once it is loaded into the clientcomputer's memory by a trusted application. In particular, the DRMOSmust prohibit the use of certain types of programs and refrain fromperforming certain common operating system procedures when content is inmemory.

An example of one kind of procedure that must be prohibited is loading akernel debugger because it would allow the user to make a copy of thecontent loaded in memory. If the user of the subscriber computerattempts to load a kernel debugger into memory, the DRMOS can either 1)refuse to load the debugger, or 2) renounce its trusted identity andterminate the trusted application that was accessing the content beforeloading the debugger. In the latter case, the memory must also be purgedof the content before the debugger is loaded. The choice of action canbe pre-determined or chosen by the user when the user attempts to loadthe kernel debugger. One of skill in the art will immediately identifyother types of programs that will need to be treated in the same manneras a kernel debugger.

Virtual memory operating systems maintain a page file that holdssections of program code and data that are not currently active. Undernormal circumstances, the contents of the page file are accessible bythe user of the computer, either by running a privileged program or bybooting another operating system that allows inspection of the disk.Therefore, a DRMOS must either protect content stored on the page fileor must not page content and similar protected information at all.

Protecting content on the page file can be accomplished in at leastthree ways. First, the DRMOS can prohibit all “raw” access to page filedevice when a trusted application is running. Second, the DRMOS canterminate all trusted applications and erase the page file beforeallowing such access. Third, the DRMOS can encrypt the content andsimilar protected information before writing it to the page file.

Often, a DRMOS must allow the user to perform certain standard functionsbut prohibit other, related functions. The DRMOS can assign the userpermissions based on the granularity of the normally permitted function.For example, the DRMOS can allow the user to delete an entire contentfile but not a portion of it. Another example is that the DRMOS canallow the user to terminate all the threads of execution for a trustedapplication but not just a single thread.

Finally, a DRMOS must protect the trusted application itself fromtampering. The DRMOS must not allow other processes to attach to theprocess executing the trusted application. When the trusted applicationis loaded into memory, the DRMOS must prevent any other process fromreading from, or writing to, the sections of memory allocated to thetrusted application without the explicit permission or cooperation ofthe trusted application

Key-based Secure Storage

In order to protect content permanently stored on the subscribercomputer, the DRMOS must provide a secure storage space. In essence, theDRMOS must securely store private keys or session keys for use withencrypted content, or provide some other mechanism for keeping thesekeys secret from other OSs or system level software. These keys can beused for the secure storage and retrieval of protected information. Inthe exemplary embodiments described in this section, the information tobe stored in a protected format is encrypted using one of a set of keysthat may be generated by a function 800 (FIG. 8) provided by the CPU.The storage key generation process is tightly coupled to the DRMOS sothat the same key cannot be generated by the CPU for an unrelatedoperating system, or by any software on another computer. Three types ofstorage keys are envisioned as illustrated in FIG. 8: an OS storage key801, an application storage key 811, and a user storage key 821. Eachkey is specific to the entity that requests it.

Beginning with the OS storage key 801, the DRMOS passes a “seed” 803 asan operand of a key-generation instruction (“GenerateKey”) 805 to theCPU and receives an OS storage key based on the seed 803 and theidentity of the DRMOS. The CPU will always return the same OS storagekey 801 when the same seed 803 is provided by the same DRMOS but willreturn a different OS storage key if the same seed 803 is provided by anunrelated operating system. Because an unrelated operating system cannotget the same key 801, it cannot read any data encrypted by the DRMOS.

In an alternate embodiment, only a single operating system storage keyis used by the DRMOS as described below. Therefore, in this embodimentonly the identity of the DRMOS is factored into the key generationfunction 800 and the seed 803 is not necessary.

An application storage key 811 is generated when an application calls anoperating system instruction (“GenerateApplKey”) 815 using a seed 813.The DRMOS passes the seed 813 through an application-specific one-wayhash function 817 to produce a hashed seed 819. The hashed seed 819 isthen passed to the CPU through the GenerateKey instruction describedabove. The resulting application storage key 811 is returned to theapplication for use. Because the GenerateKey function uses the operatingsystem's identity, the same application executing under an unrelatedoperating system cannot get the same key, and therefore cannot accessthe encrypted data, even if it requests the key using the same seed 813.Similarly, an unrelated application using the same seed 813 gets adifferent key because the DRMOS passes the seed 813 through a differenthash algorithm for each application.

In an alternate embodiment, the operating system stores decryption keysfor applications using its own identity; the applications call theoperating system to retrieve application keys. This also provides a wayfor an application to allow other applications access to its key andtherefore to the content encrypted by the key. Instead of creating asecret using a seed 813, the application passes in the access predicatefor the content. The access predicate designates values that must bepresent in the rights manager certificate for an application wishingaccess to the content. An exemplary embodiment for an access predicateis shown in FIG. 9 and described in detail in the following section. TheDRMOS supplies the seed 813 that is required to generate the applicationspecific key and passes the seed 813 through a generic one-way hash. TheDRMOS encrypts the seed 813 and the access predicate using an OS storagekey and associates the encrypted access predicate with the encryptedseed. When any application requests access to a key protected by anaccess predicate, the DRMOS compares the criteria in the accesspredicate against the rights manager certificate of the requestingapplication. An application that meets the criteria is given access tothe seed 813 and therefore to the application storage key. Because theseed 813 is encrypted using an OS storage key, an application that isrunning under an unrelated operating system will be unable to gainaccess to the encrypted data because the unrelated operating systemcannot decrypt the seed 813.

Finally, a particular user can request a key that is based on a useridentity assigned by the DRMOS or another facility that guarantees aunique identity for each user. The user supplies a seed 823 in a“GenerateUserKey_” call 825. The operating system passes the seed 823through a one-way hash 828, and then passes the resulting first hashedseed 827 through a keyed hash routine 829 to generate a second hashedseed 833. The operating system factors the user identity 831 into thekeyed hash routine 829 so that the second hashed seed 833 is unique tothe user. The second hashed seed 833 is passed to the CPU, which returnsthe user storage key 821. As described above, only the same user will beable to access data encrypted with the storage key 821 when the DRMOSthat generated the key is executing. Analogously, the keyed hash routine829 guarantees that the user storage key will not duplicate either an OSstorage key or an application storage key based on the same seed. Such afacility is used when downloaded content can be accessed only by aparticular user. Moreover, if downloaded content is to be accessed onlyby a particular user and by a particular application, the secret to bestored may be divided into parts, with one part protected by anapplication-specific key and the other part protected by a user-specifickey.

Once the data is encrypted using the storage keys, there must be a wayto recover the keys when the DRMOS identity changes (as when theoperating system is upgraded to an incompatible version or an unrelatedoperating system is installed) or the computer hardware fails. In theexemplary embodiments described here, the keys are stored off-site in a“key vault” provided by a trusted third party. In one embodiment, theDRMOS contains the IP addresses of the key vault providers and the userdecides which to use. In another embodiment, the content providerdesignates a specific key vault and the DRMOS enforces the designation.In either embodiment, when the user requests the restoration of thestorage keys, the key vault provider must perform a certain amount ofvalidation before performing the download. The validation process caninclude such actions as recording the identity of the original operatingsystem (or computer) in a revocation list, checking the frequency of therequests, and requiring a credit card number before downloading thestorage keys.

Rights Management

Most operating systems do not directly process media content, such asvideo or audio. That function is usually available through specialapplication programs. Therefore, a content provider must not only trustthe operating system but must also trust the application that willprocess the content. Content also can be accompanied by a predicatestating which applications are to be trusted to access that content, andthis statement can include a list of generic properties that implicitlydefine a set of applications. Further associating a rights managercertificate with the application provides identification of theapplication and certification of its properties. This allows the contentprovider to determine if the application fulfills the requirements ofthe content provider before downloading content, and also allows theoperating system to restrict future access to only the appropriateapplications.

One exemplary embodiment of rights manager certification is shown inFIG. 9. A list of application properties 903 is appended to the digitalcertificate fields 901 standard in some digital certificate format suchas X.509. The certificate names the application. Each entry 905 in thelist 903 defines a property 906 of the application, along with optionalarguments 907. For example, one property might be that the applicationcannot be used to copy content. Another example of a property is onethat specifies that the application can be used to copy content, butonly in analog form at 480P resolution. Yet another example of aproperty is one that specifies that the application can be used to copycontent, but only if explicitly allowed by an accompanying license.Additional examples include the right to store an encrypted copy of thecontent and to restrict such storage to only certain, acceptableperipheral devices. The property 906 can also be used to specifyacceptable helper applications, such as third-party multimediaprocessing stacks or other libraries, to be used in conjunction with theapplication named in the certificate. The certificate is signed by anoperating system vendor, content provider, or third party, certifyingthe properties of the application.

Because the content provider must trust the DRMOS and application toprotect the content from misuse once downloaded, the content providerattaches an access predicate to the content. This access predicate canalso include a license to the content. The basic functions of both theaccess predicate and the license, which were described in the systemoverview, are explained in detail next.

In one embodiment, the access predicate takes the form of a requiredproperties access control list (ACL) as shown in FIG. 10. The requiredproperties ACL 1000 contains a basic trust level field 1001, whichspecifies the minimum rights management functions that must be providedby any application wishing to process the content. These minimumfunctions can be established by a trade association, such as the MPAA(Motion Picture Association of America), or by the DRMOS vendor. Aunique identifier is used to reference a list of the minimum functions.The minimum functions list can include CPU, DRMOS, and applicationspecific requirements.

The required properties ACL 1000 can also contain one or more extendedtrust level fields 1003. The extended trust level fields 1003 containsidentifiers that specify additional rights management function that mustbe provided by the subscriber computer. For example, a requiredproperties ACL can require that only a certain version of a particularapplication be allowed access to the content. The required propertiesACL 1000 is compared against the certificates for the CPU, the DRMOS,and the application starting at the hardware level, i.e., CPU, DRMOS,application name, version, and specific properties for the application.One of skill in the art will readily recognize that the requiredproperties ACL 1000 can require that all properties must be present, orat least one of the properties, or some specified subset.

The content license (FIG. 11) imposes additional restrictions on whatkind of processing can be performed on the content once an applicationhas access to the content. As described briefly above, the license datastructure 1100 can limit the number of times the content can be accessed(usage counter 1101), determine what use can be made of the content(derivation rights 1103), such as extracting still shots from a video,or building an endless loop recording from an audio file, or atime-based expiration counter 1105.

The license can also specify whether or not a trusted application ispermitted to validate other client computers and share the content withthem (sublicense rights 1107), in effect having the subscriber computeract as a secondary content provider. The sublicense rights 1107 canimpose more restrictive rights on re-distributed content than thosespecified in a license for content downloaded directly from the originalcontent provider. For example, the license 1100 on a song purchaseddirectly from the music publisher can permit a song to be freelyre-played while the sublicense rights 1107 require a limit on the numberof times the same song can be re-played when re-distributed. To enforcethe sublicense rights 1107, in one embodiment, the trusted applicationmodifies the original license 1100 to specify the additionalrestrictions and downloads the modified license with the re-distributedcontent. In an alternate embodiment, the original content providerdownloads a sublicense along with the content and that sublicense isre-distributed by the trusted application when it re-distributes thecontent. The sublicense is structurally identical to the license datastructure 1100 although the content of the fields differs.

Additional licensing restrictions will be readily apparent to oneskilled in the art and are contemplated as within the scope of theinvention.

The license 1100 is stored with the content on secured storage. In oneembodiment, the required properties ACL 1000 is also stored with thelicense 1100 and the content. In an alternate embodiment, the ACL 1000is secured separately and controls access to the storage key for thecontent as described above.

In the embodiments described above, the DRMOS is responsible forchecking the required properties ACL and for enforcing the licensingrestrictions. By providing the validation functions in the DRMOS, thefunctions are centralized and can be utilized by any process. In analternate embodiment, the validation functions concerning theapplication are coded directly into the trusted applications programs. Asimilar effect is achieved in yet another alternate embodiment thatplaces the application validation functions in a library that isincorporated into the trusted applications.

One of skill in the art will immediately perceive that certain rightsare more easily enforced at the DRMOS level, such as the right for acertain application to access a key or other content, or the ability toopen a file a limited number of times, while other types of rights arebest enforced by the application itself. Since the DRMOS enforces therestriction that only explicitly stated applications can accessrestricted content, the application can be trusted to enforce theadditional restrictions. Alternate embodiments in which the enforcementof certain rights is allocated to the DRMOS and the enforcement ofothers to the application is therefore contemplated as within the scopeof the invention.

As described above in conjunction with FIG. 2, the content provider 220delivers content to the subscriber computer 200 after trust isestablished by transmitting the appropriate certificates/identities forthe CPU, the DRMOS, and the application to the provider. The content canbe explicitly encrypted by the content provider for this combination ofCPU, DRMOS, and application, as described above, or, if the content issent over a secured link (with, for example, Secure Socket Layerservices), the content provider can encrypt the content using thesession key for the secure link. In the latter embodiment, the DRMOSwrites the encrypted content to permanent storage and uses one of thestorage keys generated by the CPU to securely store the session key forlater use. Alternately, the content provider can choose not to encryptthe content if it is transmitted to the application in a secure fashion,in which case the application performs the encryption if it stores apersistent copy of the content.

The particular methods performed by a subscriber computer of anexemplary embodiment of the invention have been described. The methodsperformed by the subscriber computer have been shown by reference toflowcharts, operational diagrams, and data structures. Methods performedby the content provider have also been described.

Conclusion

A digital rights management system has been described whereby certaincryptographic secrets are reliably associated with a particular digitalrights management operating system or family of operating systemsrunning on a particular general-purpose computer. The operating systemuses these secrets to authenticate itself to a third party, to receiveencrypted content or information, to store this content or informationsecurely, and to retrieve it later. No unrelated operating system orother software running on the same computer can obtain these secrets andperform these actions, nor can any operating system or other softwarerunning on any other computer. By using these cryptographic secrets, thedigital rights management operating system can recursively providederived cryptographic secrets for the same uses by applications runningon the same operating system on the same computer.

Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat any arrangement which is calculated to achieve the same purpose maybe substituted for the specific embodiments shown. This application isintended to cover any adaptations or variations of the presentinvention.

For example, those of ordinary skill in the art will appreciate thatvarious combination of the exemplary embodiments are applicable to solvethe digital rights management problem depending on the exact computingenvironment. Furthermore, those of ordinary skill in the art willrecognize that the invention can be practiced on a large scale althoughillustrated herein with only a single subscriber and content provider.

The terminology used in this application with respect to is meant toinclude all hardware and software configuration and all networkedenvironments. Therefore, it is manifestly intended that this inventionbe limited only by the following claims and equivalents thereof.

We claim:
 1. A computerized method for enforcing digital rights oncontent downloaded from a provider comprising: downloading the contentfrom the provider encrypted for a particular combination of an operatingsystem and a central processing unit (CPU) of the computer; downloadingan access predicate, for the content, that specifies properties anapplication running on a computer is to have in order to process thecontent; checking the access predicate against a rights managercertificate for the application requesting access to the content;checking the access predicate against a certificate for the operatingsystem running on the computer; permitting access to the content only ifboth the rights manager certificate and the certificate for theoperating system satisfy the access predicate wherein accessing thecontent comprises decrypting the content.
 2. The computerized method ofclaim 1, further comprising: downloading a license for the content; andmonitoring the application accessing the content to determine if thelicense is being violated.
 3. The computerized method of claim 1,further comprising: terminating the access by the application if thelicense is violated.
 4. The computerized method of claim 1, furthercomprising: downloading a license for the content; and providing thelicense to the application accessing the content to enforce the license.5. The computerized method of claim 4, further comprising: storing thecontent on persistent storage; and storing the license for the contenton the persistent storage in an encrypted form.
 6. The computerizedmethod of claim 1, further comprising: storing the content on persistentstorage; and storing the access predicate for the content on thepersistent storage in an encrypted form.
 7. The computerized method ofclaim 1 wherein the elements are processed in the order recited.
 8. Thecomputerized method of claim 1, wherein the access predicate specifiesthat the application must allow only reading of the content.
 9. Thecomputerized method of claim 1, wherein the access predicate specifiesthat the application must render the content at no greater than amaximum resolution.
 10. The computerized method of claim 1, wherein theaccess predicate specifies that the application must not allow thecontent to be copied.
 11. The computerized method of claim 1, whereinthe access predicate specifies that the application must not allow thecontent to be copied in greater than a maximum resolution.
 12. Thecomputerized method of claim 1, wherein the access predicate specifiesthat the application must not allow the content to be copied unless thecontent is accompanied by a particular license.
 13. The computerizedmethod of claim 1, wherein the access predicate specifies that theapplication must not allow the content to be stored unless the contentis encrypted for storage.
 14. The computerized method of claim 1,wherein the access predicate specifies that the application mustrestrict the ability to store the content to only certain devices. 15.The computerized method of claim 1, wherein the content comprises mediacontent, and further comprising checking the access predicate against acertificate for the CPU of the computer, and wherein the permittingcomprises permitting access to the content only if each of the rightsmanager certificate, the certificate for the operating system, and thecertificate for the CPU satisfies the access predicate.
 16. Thecomputerized method of claim 15, wherein the media content comprisesaudio content.
 17. The computerized method of claim 15, wherein themedia content comprises video content.
 18. The computerized method ofclaim 1, further comprising: submitting the rights manger certificate tothe provider; and wherein downloading the content comprises downloadingthe content from the provider only if the provider determines, based atleast in part on the rights manger certificate, that the provider shouldestablish a trust relationship with the operating system.
 19. A computersystem comprising: a processing unit; a system memory coupled to theprocessing unit through a system bus; a computer-readable medium coupledto the processing unit through the system bus; an application executedfrom the computer-readable medium by the processing unit and having arights manager certificate, wherein the application causes theprocessing unit to access content; an operating system executed from thecomputer-readable medium and certified by the processing unit, whereinthe operating system determines whether the application includes a setof properties necessary to be able to process the content by causing theprocessing unit to compare an access predicate associated with thecontent against the rights manager certificate for the application whenthe application causes the processing unit to access the content, andwherein the content is encrypted by a provider for the particularcombination of the operating system and the processing unit; and whereinthe operating system decrypts the content only if the applicationincludes the set of properties.
 20. The computer system of claim 19,wherein the operating system further causes the processing unit tomonitor the application accessing the content to determine compliancewith a license associated with the content.
 21. The computer system ofclaim 20, wherein the operating system further causes the processingunit to terminate the access of the content by the application if theapplication does not comply with the license.
 22. The computer system ofclaim 19, wherein the application causes the processing unit to processthe content for the application in accordance with a license associatedwith the content.
 23. The computer system of claim 22, wherein theapplication further causes the processing unit to modify the license tocreate a sublicense and to transfer the sublicense and the content toanother computer system.
 24. The computer system of claim 22, whereinthe application further causes the processing unit to transfer asublicense and the content to another computer system.
 25. The computersystem of claim 19, further comprising: a helper application executedfrom the computer-readable medium by the processing unit and under thecontrol of the application, wherein the helper application causes theprocessing unit to perform additional processing the content.
 26. Thecomputer system of claim 19, further comprising: a different applicationexecuted from the computer-readable medium by the processing unit,wherein the different application causes the processing unit to accessthe content for the different application using the rights managercertificate of the application.
 27. The computer system of claim 19,wherein the content comprises media content, wherein the operatingsystem determines whether the application includes the set of propertiesnecessary to be able to process the content by further causing theprocessing unit to compare a certificate for the operating system to theaccess predicate and compare a certificate for the processing unit tothe access predicate, and wherein the operating system permits access tothe content only if each of the rights manager certificate, thecertificate for the operating system, and the certificate for theprocessing unit satisfies the access predicate.
 28. The computer systemof claim 19, wherein the operating system further causes the processingunit to submit the rights manager certificate to a provider of thecontent, and wherein the application downloads the content only if theprovider determines, based at least in part on the rights managercertificate, that the provider should establish a trust relationshipwith the operating system.
 29. One or more computer-readable mediahaving stored thereon a computer program that, when executed by one ormore processors, enforces digital rights on content downloaded from aprovider by causing the one or more processors to: download the contentfrom a provider encrypted for a particular combination of an operatingsystem and the one or more processors; download an access predicate, forthe content, that specifies properties an application executed by theone or more processors is to have in order to process the content; checkthe access predicate against a rights manager certificate for theapplication requesting access to the content; check the access predicateagainst a certificate for the operating system executed by the one ormore processors; permit access to the content only if both the rightsmanager certificate and the certificate for the operating system satisfythe access predicate wherein access to the content comprises decryptingthe content.
 30. One or more computer-readable media as recited in claim29, wherein the computer program further causes the one or moreprocessors to: download the access predicate with the content.
 31. Oneor more computer-readable media as recited in claim 29, wherein thecomputer program further causes the one or more processors to: downloada license for the content; and monitor the application accessing thecontent to determine if the license is being violated.
 32. One or morecomputer-readable media as recited in claim 29, wherein the computerprogram further causes the one or more processors to: store the contenton persistent storage; and store the access predicate for the content onthe persistent storage in an encrypted form.
 33. The computer system ofclaim 19, wherein the access predicate includes properties that specifythat the application must do one or more of the following: allow onlyreading of the content, render the content at no greater than a maximumresolution, not allow the content to be copied, not allow the content tobe copied in greater than a maximum resolution, not allow the content tobe copied unless the content is accompanied by a particular license, notallow the content to be stored unless the content is encrypted forstorage, and restrict the ability to store the content to only certaindevices.
 34. One or more computer-readable media as recited in claim 29,wherein the properties an application is to have in order to process thecontent comprises both a name of the application and a version of theapplication.
 35. One or more computer-readable media as recited in claim29, wherein the content comprises media content, and wherein thecomputer program further causes the one or more processors to: check theaccess predicate against a certificate for the one or more processors,and wherein the computer program causes the one or more processor topermit access to the content only if each of the rights mangercertificate, the certificate for the operating system, and thecertificate for the one or more processors satisfies the accesspredicate.
 36. One or more computer-readable media as recited in claim29, wherein the computer program further causes the one or moreprocessors to: submit the rights manager certificate to the provider;and download the content from the provider only if the providerdetermines, based at least in part on the rights manager certificate,that the provider should establish a trust relationship with theoperating system.